Skip to content

Conversation

@Br-DiorD
Copy link
Contributor

Initial implementation of the Karumi Screenshot testing package with Compose UI testing combined.

Code uses Compose UI tests to collect the screenshots and karumi to save and compare them

Please see the Screenshot Testing: Compose UI x Karumi Confluence page created

Copy link
Contributor

@BottleRocket-Colin BottleRocket-Colin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to adjust font size so screen shots look reasonable?

@Br-DiorD
Copy link
Contributor Author

@BottleRocket-Colin so the font size is still a pending questions for me. The tests are suppose to run as and we shouldn't have to add that but I will continue to look into solution.

compareScreenshot(composeRule.onRoot())
}

fun renderComponent(state: HomeScreenState? = null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Br-DiorD Think I figured out our issue. We should wrap HomeScreen like this:

ArchitectureDemoTheme {
HomeScreen(state)
}

Also, Could HomeScreenState in function signature be non null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BottleRocket-Colin nice! I'll give it a shot after this meeting. I do wonder why it is only an issue on certain screenshots because the Pull RequestScreenshot shot is fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Br-DiorD _ would say that the PR request screenshot is probably not correct but just closer to being correct. It's a matter of where our h4 and h5 typographies are closer to the default sizes but our h1 is very small compared to the h1 default. So some screens will show closer to correct than others depending on which typography elements are being used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BottleRocket-Colin fixed. Sorry for the delay :)

@jaredstockton
Copy link
Contributor

@Br-DiorD I'll take a look at this tomorrow and provide some feedback!

Copy link
Contributor

@jaredstockton jaredstockton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I'm currently unable to execute the tests OR record new screenshots for my API 31 Pixel 4 emulator. I'm going to continue to look into this.

@Br-DiorD It would be awesome if there was some way to dictate the emulator configuration to be used to run the tests so any dev would be able to run the tests on their machine and get the same results. If there isn't a programmatic way to do that, even just listing the emulator configuration in the README.md would be helpful

@jaredstockton
Copy link
Contributor

Note that I'm currently unable to execute the tests OR record new screenshots for my API 31 Pixel 4 emulator. I'm going to continue to look into this.

tldr; Turns out I needed to uninstall a previously installed Architecture Demo build before attempting to run the integration tests.

Findings:
The Android Studio logs mentioned this error: Unknown platform error occurred when running the UTP test suite. Please check logs for details.
Not too helpful but there was also a reference to a pb file (app/build/outputs/androidTest-results/connected/flavors/internal/test-result.pb). I opened it in a text editor (Visual Studio Code, specifically) and saw that the root cause of the failure mentioned within:

Message: Failed to install APKs: INSTALL_FAILED_SHARED_USER_INCOMPATIBLE

jaredstockton and others added 2 commits August 19, 2022 17:37
…oid-ArchitectureDemo into feature/ASAA-23-karumi

� Conflicts:
�	app/src/main/java/com/bottlerocketstudios/brarchitecture/ui/repository/RepositoryCommitViewModel.kt
@Br-DiorD
Copy link
Contributor Author

Br-DiorD commented Sep 9, 2022

@br-jared-stockton Got to remind myself to add this to the confluence but yes you have to uninstall previous app version IOT get the test to run because the addition of the sharedUserId in the Manifest requires a complete reboot to implement itself i guess.

@jaredstockton
Copy link
Contributor

jaredstockton commented Sep 9, 2022

@Br-DiorD It would be awesome if there was some way to dictate the emulator configuration to be used to run the tests so any dev would be able to run the tests on their machine and get the same results. If there isn't a programmatic way to do that, even just listing the emulator configuration in the README.md would be helpful

@Br-DiorD This is the last thing I'd like to see done for this PR, primarily so that devs/CI can setup an emulator to get consistent results (meaning any team member could setup their emulator with some given configuration and run the snapshot tests successfully). I imagine that the emulator would match the emulator used to check in the screenshots :)

@Br-DiorD
Copy link
Contributor Author

Br-DiorD commented Sep 9, 2022

@br-jared-stockton on it. I don't remember having to do anything on the emulator for it to work so I'm going to create a new 1 and start from scratch to see what happens 👍

@Br-DiorD
Copy link
Contributor Author

@br-jared-stockton updated with link to Confluence where I added Emulator setup steps. Link can be found in both the Base test file and the README.md file.

@jaredstockton
Copy link
Contributor

updated with link to Confluence where I added Emulator setup steps. Link can be found in both the Base test file and the README.md file.

@Br-DiorD I was thinking of something more along the lines of the scripts that are in the shot-consumer folder of the shot dependency: https://github.com/pedrovgs/Shot/tree/master/shot-consumer/scripts

The idea is that a new developer would be able to execute create_emulator.sh and start_emulator.sh and validate all screenshots OR add new screenshot tests that match the screenshots already present (effectively the same emulator with same OS + screen width + screen height + pixel density)

You could copy/paste those initial scripts into the architecture demo project and then tweak to suite (if you want to use api 31 and different screen width/height values, etc).

Then you'd need to retake all screenshots with the emulator created from the script.

Once all of that is done, then anybody would be able to run the screenshot tests and take new ones that match the existing emulator criteria without having to manually create/configure a new emulator on their machine :D

Copy link
Contributor

@jaredstockton jaredstockton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants